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(54) A method of updating firmware without affecting initialization information 



(57) A firmware controlled device saves status and 
configuration information in a separate portion of mem- 
ory (104, 106) that is not affected by a firmware update. 
In addition, information that may change during a 
firmware update, and may need to remain constant, is 
saved in the separate portion of memory that is not 
affected by a firmware update. In a first example 
embodiment, a reset process for the firmware controlled 
device is divided into two portions. In a first portion 
(202) of the device reset process, the contents of the 
separate portion of memory are updated, either from 
firmware or by interaction with other devices. In a sec- 
ond portion (204) of the device reset process, all other 
reset functions are performed. The first portion of the 
reset process is performed only during a power-on 
reset, or in response to an overall system reset. In par- 
ticular, the first portion of the device reset process is not 
performed after a firmware update (206). In the second 
example embodiment, data that needs to remain con- 
stant are copied (308) to the separate portion of mem- 
ory as part of a firmware update process (304). Then, 
as part of a reset process, the device checks (314) to 
see if a firmware update has occurred. If a firmware 
update has occurred, the data in the separate portion of 
memory are copied (318) to the appropriate destina- 
tions, and the data in the separate portion of memory 
are cleared (320). As a result, for either example 
embodiment, the contents of the separate portion of 
memory are not disturbed during or after a firmware 
update, and a system reboot is not necessary after a 
device firmware update. 
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Description with a series of transitions indicating sequential bit posi- 
tions within each identifier. As a result of interaction 

FIELD OF INVENTION between the host computer and the I/O cards, one card 

is isolated and assigned a logical device number. The 

[0001] This invention relates generally to micro- 5 sequence is then repeated to isolate another card and 

processor controlled devices and more specifically to so forth until all cards have been assigned a logical 

modification of firmware without requiring the device to device number. 

be shut down and without requiring an overall system [0005] Another common interface standard is the 

reset. Small Computer System Interface (SCSI). SCSI also 

10 requires a unique ID for each device. An industry group 

BACKGROUND OF THE INVENTION has proposed a set of specifications, called Plug and 

Play SCSI, which among other things provides auto- 

[0002] In many devices controlled by a microproc- matic assignment of unique SCSI ID'S. The particular 

essor, there is a need for occasional modification or protocol for assignment of unique ID'S is called SCSI 

updates to the firmware. Historically, firmware was is Configured AutoMagically (SCAM). Each SCAM com- 

stored in a read-only-memory (ROM), and firmware patible device has a default ID saved in a nonvolatile 

modification was accomplished by replacing one or device memory. A SCAM master device first commands 

more ROMs. Replacement of ROMs typically required each of the other SCAM devices, one at a time, to go 

at least turning power off for a product and often into an inactive state. Then, the master device uses a 

required partial disassembly of a product. More 20 protocol similar to the protocol for ISA Plug and Play to 

recently, various types of programmable (write-once) or isolate each device for assignment of a SCSI address, 

rewriteable nonvolatile memory is used, or sometimes [0006] There are other configuration protocols used 

battery powered volatile memory may be used. It is now by peripheral devices. If multiple devices are on one 

common to send firmware updates electronically to a input/output port, devices may automatically configure 

device and have the device modify or replace its own 25 themselves, at power-on, as primary and secondary 

firmware. For example, modem firmware updates may devices. A device may need to record its own status (pri- 

be communicated over a telephone line and a modem mary or secondary) and whether or not another device 

may update its firmware without requiring opening of the is sharing the same I/O cable. 

modem's housing. [0007] In the second set of examples, some infor- 

[0003] Typically, updating firmware in a running sys- 30 mation that a device shares with other devices, or data 

tern may erase or change information that needs to that the device uses for various control functions, may 

remain unchanged until the next system reset. Typically, change when firmware is updated. If the information is 

updating firmware in one device of a large system may communicated to other devices only during power-on or 

require the entire system to be reset or rebooted. There reboot, then the information used by a device after a 

is a need in some systems for the ability to update 35 firmware update may be inconsistent or inappropriate. A 

firmware within one device but to maintain integrity of system reboot may then be necessary. For example, 

some data and to continue operation without requiring consider again an identifier. Part of an identifier may 

an overall system reset or reboot. The following discus- indicate a firmware version or date code. Operating sys- 

sion provides two examples of devices where there is a tern software or other system devices may poll devices, 

need to preserve data during a firmware update. The 40 at power-on or system reboot, and record a list of device 

first set of examples involves data being gathered and identification numbers. Applications software may read 

transmitted during initialization after a system reset. The such a list, and applications software may later refer to 

second set of examples involves data that a device may a specific device identifier. If a firmware update changes 

need to communicate to other devices, or data that may a device identifier, for example by changing a firmware 

affect external operation. 45 version number, a system reboot may be required to 

[0004] Many computer based systems undergo an update information gathered by the operating system or 

automatic configuration process during an initialization other system devices during system reboot. As an alter- 

process after power-on or during a reboot process. Typ- native example, consider a value, stored in firmware, 

ically, this requires all devices to run various initialization that is written to a register of a control circuit during 

processes simultaneously. For example, for Intel com- 50 reset. If this value changes during a firmware update 

patible personal computers, one industry specification and the firmware is restarted, the control circuit output 

for automatically configuring I/O boards for the ISA bus may change inappropriately. 

is called the Plug and Play ISA Standards. For ISA Plug [0008] From the above examples, there is a need 

and Play, each compatible I/O card has a unique identi- for firmware updates that are transparent to a computer 

fier that includes a vendor identifier and a serial number. 55 system or operator, so that a system reboot is not 

Each compatible I/O card can read its own identifier. required. 
The host computer first places all the cards into a con- 
figuration mode. Then the host computer drives a line 
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SUMMARY OF THE INVENTION 

[0009] A firmware controlled device, in accordance 
with the invention, saves status and configuration infor- 
mation in a separate portion of memory that is not s 
affected by a firmware update. In addition, information 
that may change during a firmware update, and may 
need to remain constant, is saved in the separate por- 
tion of memory that is not affected by a firmware update. 
In one example embodiment, the data in the separate 10 
portion of memory are overwritten during a hard reset 
(power-on reset or overall system reset). In a second 
example embodiment, data are copied to the separate 
portion of memory at the beginning of a firmware 
update. is 
[0010] In the first example embodiment, a reset 
process for the firmware controlled device is divided into 
two portions. In a first portion of the device reset proc- 
ess, the contents of the separate portion of memory are 
updated, either from firmware or by interaction with 20 
other devices. In a second portion of the device reset 
process, all other reset functions are performed. The 
first portion of the reset process is performed only dur- 
ing a power-on reset, or in response to an overall sys- 
tem reset. In particular, the first portion of the device 25 
reset process is not performed after a firmware update. 
[0011] In the second example embodiment, data 
that needs to remain constant are copied to the sepa- 
rate portion of memory as part of a firmware update 
process. Then, as part of a reset process, the device 30 
checks to see if a firmware update has occurred. If a 
firmware update has occurred, the data in the separate 
portion of memory are copied to the appropriate desti- 
nations, and the data in the separate portion of memory 
are cleared. 35 
[001 2] As a result, for either example embodiment, 
the contents of the separate portion of memory are not 
disturbed during or after a firmware update, and a sys- 
tem reboot is not necessary after a device firmware 
update. 40 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0013] 

45 

Figure 1 is a block diagram of a processor system 
capable of updating firmware in accordance with 
the invention. . 

Figure 2 is a state diagram and flow chart for a first so 
example method of updating firmware in accord- 
ance with the invention. 

Figure 3 is a state diagram and flow chart for a sec- 
ond example method of updating firmware in 55 
accordance with the invention. 



DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENT OF THE INVENTION 

[0014] Figure 1 illustrates a block diagram of an 
example embodiment of a processor system, within a 
device, in accordance with the invention. A processor 
100 can communicate externally (to other parts of the 
device, or externally to the device) through an input/out- 
put (I/O) port 102. The processor 100 can read and 
write to volatile memory 104, nonvolatile memory 106, 
and perhaps various latches and registers (110) within 
other device circuitry. The term "volatile memory" 
means that the stored information is lost when power is 
off. An example is RAM, and also latches and registers. 
The term "nonvolatile memory" means that stored infor- 
mation is not lost when power is off. Examples include 
read-only-memory (ROM), programmable read-only 
memory (PROM), electrically alterable read-only mem- 
ory (EPROM), magnetic devices such as core memory, 
and may include a mass-memory medium, for example 
a tape or disk. Typically, firmware 108 resides in nonvol- 
atile memory 106. However, as discussed below, the 
processor 100 may also execute code residing in vola- 
tile memory. Firmware 108 may include both instruc- 
tions and data. New firmware, or modifications to 
firmware, may be received over the I/O port 102. 
[0015] In the first example embodiment, during a 
power-on initialization sequence, or during a reset in 
response to an overall system reset, some information 
is saved in a separate area of memory other than within 
the area designated as firmware 108. In addition, some 
information may be read from the firmware 108 and 
stored in the separate area of memory. The separate 
area of memory may be within the volatile memory 104 
or within the nonvolatile memory 106. When the 
firmware 108 is updated, the separate area of memory 
is not affected, either during the update or during a 
device soft reset after the update. 
[0016] In the second example embodiment, during 
a firmware update, essential information is copied, from 
locations that are subject to change during the firmware 
update, to a separate area of memory. After the 
firmware update, a test is performed to see if a firmware 
update has occurred. If a firmware update has 
occurred, the information that was copied to the sepa- 
rate area of memory is copied back to its original loca- 
tion^). 

[0017] In the following discussion, an autoconfigur- 
ing device is used as an example to facilitate illustration. 
However, the invention is applicable to any device that 
needs to be able to update firmware without requiring 
an overall system power-on reset or reboot. The exam- 
ple device has an electronically readable identification 
that includes a firmware version number. The example 
device may share an I/O cable with at least one other 
device. Each device sharing the I/O cable must deter- 
mine whether another device is present on the same I/O 
cable. If another device is present, each device sharing 
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the I/O cable must execute a process to determine 
which device is the primary device and which device is 
the secondary device. This configuration information 
must be determined and saved during a power-on ini- 
tialization or system reboot. 5 
[0018] Figure 2 illustrates a first example embodi- 
ment of a portion of the firmware. In figure 2, the 
firmware is depicted as having an idle process 200, 
which may transfer to one of three other processes: a 
hard reset process 202, a soft reset process 204, or a 10 
firmware update process 206. Note that the terms "hard 
reset" and "soft reset" may be used for an overall sys- 
tem, but in figure 2 the terms refer only to processes 
within one firmware controlled device. The idle process 
(200) in figure 2 is just an example of process branch- 15 
ing. There are many ways in which a process may 
branch to other processes. In general, a running proc- 
ess may be interrupted (for example, by a reset signal) 
or a process may check for certain conditions or flags to 
control branching to different processes. 20 
[0019] If a hard reset is required (for example, a 
particular command, a power-on initialization, or a sys- 
tem interrupt or other signal indicating an overall system 
reset), the firmware copies some internal device-spe- 
cific data, from nonvolatile memory that is subject to 25 
change during a firmware update, to a separate section 
of memory that is not subject to change during a 
firmware update (step 208). For example, the device 
identification may be used during autoconfiguration, 
and the device identification may change during a 30 
firmware update. In the example, at step 208, the device 
identification is copied into a part of memory that is not 
changed during a firmware update. Then, during auto- 
configuration, and during operation until another hard 
reset, the copied version is used, not the original. 35 
[0020] The separate section of memory may be in 
the nonvolatile memory 104, or the separate section of 
memory may be part of the nonvolatile memory 106. 
The choice may depend on the technology used for the 
nonvolatile memory. If nonvolatile memory can be par- 40 
tially modified, the firmware may copy some data, from 
nonvolatile memory that is subject to updating, to a sep- 
arate part of the nonvolatile memory that is not subject 
to updating. However, if the nonvolatile memory must be 
entirely rewritten, then the data may be copied into the 45 
volatile memory. After autoconfiguration (step 210), 
configuration information is saved in the separate mem- 
ory (either volatile memory or a portion of nonvolatile 
memory that is not changed during a firmware update) 
(step 212). so 
[0021] If a signal or command is received to update 
the firmware, non-changing update code reads the new 
firmware (for example, via the I/O port) and writes the 
new firmware into the nonvolatile memory (process 
206). If the nonvolatile memory 106 can be partially 55 
modified, then a portion of the nonvolatile memory may 
be reserved for update code that does not change dur- 
ing a firmware update. The non-changing update code 




099 A2 6 

then reads the new code and replaces the old. In figure 
1 , nonvolatile memory 106 is depicted as having a sep- 
arate firmware section 108 that is updated. Alterna- 
tively, firmware update code may be copied from the 
nonvolatile memory to the volatile memory, and the 
processor 100 may then execute update code in the vol- 
atile memory during a firmware update. If update code 
is executed from volatile memory, the entire nonvolatile 
memory 106 may be updated. In some systems, the 
nonvolatile memory may be rewriteable, in which case 
old firmware may be overwritten. In other systems, the 
nonvolatile memory may be write-once, in which case 
the new firmware is written into a new area of memory 
and a pointer is changed to point to the new firmware 
instead of the old firmware. 

[0022] After the firmware has been updated, the 
soft reset process (204) is entered. The soft reset proc- 
ess (204) comprises all the various tasks (step 214) 
involved in a reset process that don't impact the infor- 
mation saved in steps 208 and 212. For example, for 
mass memory peripherals, a transducer may need to be 
moved to a starting point. 

[0023] The method illustrated in figure 2 may not be 
suitable for all devices. For example, some devices may 
not have the equivalent of hard reset and soft reset. In 
addition, in some devices, a slightly different result may 
be needed. Consider, for example, that during the reset 
process, firmware writes a value to a register (figure 1 . 
1 10) that is used by a control circuit. After a firmware 
update, that control value should not change, but after 
any reset, the current control value should be used. Fig- 
ure 3 illustrates a method suitable for the requirement 
just described. The firmware portion in figure 3 does not 
have a soft reset. The idle process 300 may branch to 
either a hard reset 302 or to a firmware update process 
304. After a hard reset, the firmware performs an auto- 
configure process 306. During a firmware update, some 
information is copied from a default location to the sep- 
arate portion of memory (step 306). For example, a 
value that will be written to a register may be copied 
from a firmware location to the separate portion of 
memory. At steps 310 and 312, the firmware is updated 
and restarted. After either a hard reset or a firmware 
update, the firmware tests to see if a firmware update 
has occurred (step 314). For example, the firmware may 
check the separate portion of memory to see if it con- 
tains data or has been cleared. If no firmware update 
has occurred, the default values are used (step 316). If 
a firmware update has occurred (step 318), the 
firmware uses the values that were earlier copied to the 
separate portion of memory (that is, the values copied 
at step 308). As an alternative to step 31 8, if a value has 
already been written to a register, step 318 may be to do 
nothing. That is, instead of updating the destination reg- 
ister as in step 316, step 318 may simply leave the reg- 
ister undisturbed. In the firmware illustrated in figure 3, 
if a reset occurs, the new values are to be used, so the 
values saved in the separate portion of memory are 
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cleared (step 320) immediately after being copied to the 
appropriate destinations (for example, a register). 
[0024] The two methods illustrated in figures 2 and 
3 are not mutually exclusive, but instead may be 
merged, or portions of each may be used as appropri- 
ate. Each figure illustrates a slightly different solution 
depending on the needs of a device. Some information 
may need to survive a soft reset (figure 2) and other 
information may need to survive a firmware update but 
be refreshed after a reset (figure 3). 
[0025] In summary, for the device and methods 
described above, the information saved in separate 
memory is not disturbed by the firmware update proc- 
ess, or by the device reset process immediately follow- 
ing a firmware update. As a result, an overall system 
reboot process is not required. Note that information 
transferred from firmware to the separate memory may 
be inaccurate after the software update and before the 
next system reboot (for example, a firmware version 
number may be incorrect), but this result may be prefer- 
able to requiring an immediate system reboot. 
[0026] The foregoing description of the present 
invention has been presented for purposes of illustration 
and description. It is not intended to be exhaustive or to 
limit the invention to the precise form disclosed, and 
other modifications and variations may be possible in 
light of the above teachings. The embodiment was cho- 
sen and described in order to best explain the principles 
of the invention and its practical application to thereby 
enable others skilled in the art to best utilize the inven- 
tion in various embodiments and various modifications 
as are suited to the particular use contemplated. It is 
intended that the appended claims be construed to 
include other alternative embodiments of the invention 
except insofar as limited by the prior art. 
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(a) obtaining (210) information during an initial- 
ization process; 

(b) saving (212) the information from step (a) in 
a second section of memory; and 

(c) changing (206) the firmware in the first sec- 
tion of memory without changing the second 
section of memory. 



Claims 



1 . A method of changing firmware comprising: 



(a) copying (208, 308) information, which 
needs to remain unchanged, from a first sec- 
tion of memory (108) to a second section of 
memory (104, 106), the firmware residing in 
the first section of memory; and 

(b) changing (206, 310) the firmware in the first 
section of memory without changing the sec- 
ond section of memory. 

2. The method of claim 1 further comprising: 

(a1) obtaining (210) information during an ini- 
tialization process; and 

(a2) saving (212) the information of step (a1) in 
the second section of memory. 



3. 



A method of changing firmware in a first at section 
of memory, comprising: 
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